Posture & Altitude — A Framework for Barriers in Service Onboarding

In 2005, the Pontiac Aztek entered the auto market, blazing a new trail for car buyers whose main concern was making sure that their vehicle looked kind of like an auto-morphized guinea pig.

This SUV is largely considered a flop, and the muddy, porcine aesthetics played a role. But more broadly, it was before its time: mid-sized, crossover SUVs are commonplace now, a clear niche in the market, but at the time this vehicle was... kind of hard to make sense of for buyers.

Getting your head around new stuff as a consumer is hard, and it's part of what makes launching new stuff hard. New technology, new products, new service, even new bundles of old features and ideas. People who make stuff sometimes bring an "if we build it, they will come" attitude, but the reality is that history is a graveyard of things brought to life before their time.

In 2021, we worked on a new type of broad, elective genetic wellness service. On paper, it sounded great, helping folks proactively understand their future health risk and thus take action before risks turned into symptoms. In practice, it was a hard sell, for a few reasons:

• Customers were unfamiliar with the core value proposition of this kind of assessment and the technology it used
• There were objections from customers around how baked the science was and how accurate the results were
• Customers were concerned about whether their doctors would be willing to accept and act on the results, and raised objections about how their data would be managed and shared once it was generated
• There was also confusion about how to send in their sample, how to access results, and what to do next once they got them

Navigating Onboarding Journey Posture & Altitude

As service designers, it's often our job to set the conditions that make it as easy as possible for someone to embrace a thing they haven't done or seen or used before. In some contexts, this is 'onboarding', in others 'triage', 'intake', 'purchase'. Good service designers think about the warm hug of an omnichannel experience where there's consistency and calm wherever you turn. We think about who you might talk to along the way, and what steps and stages need to get done in what order.

There's a risk, though, in approaching this passively. We'll build our library of resources, we'll draft FAQs, the chat window or call centre are there if you need it. These are important, but insufficient. Folks get lost in the ocean of possible considerations and may never find their way to the sign-up or check-out or confirmation flow. Missing domain knowledge, unclear time-to-complete, murky ROI, murkier pricing, oddball edge cases... these can all stand in the way.

Instead, we like to think of this as a micro-journey, with clear steps, stages, and sign-posting, mostly focused on removing conceptual barriers for folks as they advance through their onboarding journey. The specifics of the journey look different in every service, but the broad strokes are often governed by the intersection of posture and, for lack of a better term, altitude.

Posture refers to the cognitive and emotional posture that a prospective service user might adopt as they consider onboarding, and which stand in the way of accessing the service's value. In general, we split these frictions out into two sets:

• Confusion: this is a 'wait, what?' posture, where the service user needs greater clarity, certainty, or detail in order to advance. Often this is a more open-ended posture, where the service user doesn't know what they don't know
• Objection: this is a 'wait, no!' posture, where the service user has concerns that leave them in a position of declining the service until those concerns are addressed. This is typically a more closed posture, where the concerns are specific and in some cases acute

Altitude refers to the conceptual 'zoom' of the service user's confusions or objections, which can help us think about the levers we need to pull to address those postures. In general, we split altitude into two familiar sets:

• Value Proposition: these are issues at the 10,000ft level, related to the fundamental nature of the offering, the value it creates in the service user's life, and how they might integrate it into their conceptual framework for 'getting things done' in the world
• Implementation: these are issues at ground level, related to the specific operationalization of the service within their lives -- the nitty-gritty of how it works, how they access it, how it fits with the existing portfolio of products and services they use, how it's supported and how they troubleshoot

Most folks exploring a novel product or service are going to experience a mix of both confusion and objection, across various altitudes. Addressing them all at once is overwhelming; sitting back and letting them hunt for answers is going to frustrate. So how do we address these barriers in an orderly fashion?

As we noted above, posture and altitude intersect, making a tidy little 2x2:

Nice, right? We've now got four clear buckets of stuff to address before someone buys in to our service and gets started. But as service owners, where do we start in addressing those buckets? Here's the order we tend to find most helpful, mapping to the rational and emotional journey that the service user is naturally going through:

First, service users are confronted by Value Proposition Confusion. Folks need to understand what value they're trying to access here, what this thing is even for, before they can move on to deeper consideration of how it works for them.

Next, once they understand what the Value Proposition is, they're liable to start throwing up Value Proposition Objections, which are usually some variation of 'this is not for me': do I need this? Does this duplicate service value I'm already able to access?

If they can wrap their head around what the value proposition is, and can figure out how it might create value for them, then we can reasonably expect for their altitude to shift towards implementation of the service in the specific context of their life. Here, we stay in the Objections headspace first: before they get any deeper into figuring out the 'how' of accessing this value, they want to make sure it's not a dead end. So a service user's headspace is no longer 'this is not for me', but instead becomes 'this will not work in my world', anchoring on edge cases, fit-for-need, and other specifics of implementation.

Finally, if the service can address those concerns, the service user's posture shifts: they understand the value, they're clear on how it works for them, and their objections around implementation have been addressed. Now, their objecting posture softens into a confusion posture, still focused in on implementation: I'm bought in, but how do I get this to work? This is the territory of manuals, help articles, and chat support.

Our genetic wellness example from before maps onto this framework neatly:

• Value Proposition Confusion: What is this tech and how is it used?
• Value Proposition Objection: Is the science real? Are the results trustworthy?
• Implementation Objection: Will my doctor accept and act on these results? Will my data be managed securely?
• Implementation Confusion: How do I collect and send in my samples? How will I access my results?

In plainer language: show people the doorway, convince them it’s not going to be a mistake to step through, then once they’ve decided to do so, help them take the step.

Addressing Posture & Altitude through the Journey

Now that we've laid out the shifting postural landscape, what can we do with it?

In general, this framework helps us:

• Anticipate folks’ informational and decision-making needs at different points in the journey
• Design experiences that meet them where they’re at in different parts of the journey
• Design specific touchpoints (e.g. landing pages, chat flows, paper supports, etc.) to help people through the confusion > objection > confusion loop

What we've looked at so far is a descriptive framework, in that it tells us about service users and their postures as they move through the journey.

What we need now is to think prescriptively, to get to the 'so what' and 'now what'.

In its most generic form, you can respond to the posture/altitude framework with the following sequence:

Super-crystallized value proposition > objection handling around value > objection handling around implementation > support materials to tackle challenges that arise

Let's look at a case study.

In 2022, we worked with a telecom company that was looking at ways of reinvigorating their portfolio of entertainment offerings. They set up a bunch of partnerships with streaming services, and were bundling them together to offer several subscriptions for a bundled, discounted price.

This sounds straightforward, but in practice it was messy:

• Customers weren’t used to seeing this player as a mediating player in paying for and accessing these types of content in this way (Value Proposition Confusion)
• The value proposition (pay for a handful of streaming services one time, through one central player, at a slight discount) wasn’t familiar, and was reminiscent of the ‘legacy’ part of their perception (inflexible, expensive cable packaging), with a negative halo effect (Value Proposition Objections)
• Customers were concerned about what introducing this mediating player into their existing ecosystem would do for things like recommendations, viewing history, family account arrangement, etc. (Implementation Objections)
• The brass tacks of transitioning from their existing billing setup to this new one was… confusing! (Implementation Confusion)

If we look at the product discovery and purchase flow for this service, we can see responses to the framework unfolding neatly.

First, they lay out the value proposition clearly:

Below the headline and the first few sentences articulating the value proposition, the page immediately gets ahead of Value Proposition Objections, specifically related to a) price, and b) how it intersects with your existing portfolio of services.

As we scroll down, the price objection handling gets sharper: here are the plans, here's what it costs:

Then, beyond that, even greater clarity around the service's specifics to address concerns about value:

Finally, there are call-outs for specific features of the bundles, going deep into the value add of these bundles:

Next, it pivots into FAQs, working to address any Implementation Objections:

Then, once you're bought in, there's significant support material to help you navigate the Implementation Confusion inherent in next steps:

Cool, right?

Posture & Altitude Across the Service Life & Hype Cycle

This framework of posture and altitude manifests differently depending on who's in your target market and where your product or service is in the lifecycle of novelty to start-up to mass-market adoption.

In fact, we can map it to the classic innovation diffusion curve developed by sociologist Ev Rogers.

Innovators, or users of very early-stage services, just need to understand a compelling Value Proposition -- they can work through their objections and confusion beyond that if it's good enough and if they've got an innovation mindset. Think of scenarios where a service launches with a landing page that consists of a headline, some splashy graphics, and a "be the first to sign-up" email subscription form.

Early adopters are similar, but value proposition objections may have kept them from being in the very first cohort of service users. Implementation frictions, though, are a secondary concern -- they're willing to live with that trouble to get the value they see.

The early majority need to see their objections handled both in terms of value proposition and implementation. It's not enough for the service to offer value; they also need to understand how it fits in their life. But they're unlikely to let implementation confusion, the brass tacks of making the service work for them, stop them; this group has enough system know-how to get through these barriers. Often a service that's starting to scale may not have a fully-fleshed-out self-serve support function, because they expect their early majority users to act with agency in solving their own problems.

Beyond that, to scale out to the late majority and the laggards, you've got to address the full set of postures and altitudes.

Applying the Framework Practically

Now that we've gotten through the theory, when and where can you bring this to bear in your own practice?

First, we think it's useful as a general design planning framework, up the abstraction gradient from service-specific journey maps or site-specific information architecture. You could use it to pattern the broad onboarding journey you're building, or to tag the content hierarchy you're building.

Second, we imagine that it might be a helpful lens for auditing existing services. Do you address these postures and altitudes throughout the service? Are you addressing them in the places or at the times that your service users might reasonably expect them to be addressed, given where their heads are likely at?

Finally, we'd encourage teams to abstract this out from specific transactional service journeys and think about other scenarios where you need to bring people along. For example, we've worked with a not-for-profit to convene a distributed set of partners with varying cultures and capacities into a unified network with a shared mission. This kind of framework is equally useful for coalition-building: show the value of the network, address concerns about how it's going to create value for its members and their stakeholders, address concerns about how it's going to work practically, then work through the details of network setup and governance.

Want to talk more about bringing order to journeys through frameworks like this one? Give us a shout!